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Remarks 

This paper is responsive to a non-final Office action mailed July 1 6, 2004. In that action, 
claims 6-10 were rejected under 35 USC ! 1 2, second paragraph- 
More specifically, claim 6 was rejected on the basis that the meaning of the prhase 
"existing code sequences identified in the base file into a modified form of the base file" was 
unclear. Applicants' attorney does not feel the quoted phrase was unclear when read in the 
context of the paragraph in which it was included. However, the phrasing could be improved and 
the paragraph has been amended to recite 

"executing the directives received in the delta distribution package to combine new code 
f sequences received in the delta distribution package and existing code sequences 

identified in the base file to create a modified form of (he base file." 
The amended language is believed to fully satisfy the requirements of 35 USC 1 12. Support for 
the language can be found at page 1 1 , line 1 through page 1 2, line 5 , of Applicants* 
specification. 

Claims 7-9 were rejected on the basis the meaning of the word "generating" was unclear 
in system claims. The word has been changed to "generator" in each of this claims where 
appropriate. , Support for the changes can be found at page 8, line 21 , through page 10, line 10, 
of Applicants' specification. 

Claim 10 was rejected on the basis that it was unclear what a recited receiver was to be 
used for. The claim has been amended to recite that the receiver is used for receiving a delta 
distribution package. Support can be found in a number of places in the specification, including 
page 7, lines 11-20. 

It is noted that the Office action did not apply any art rejection to the claims because of 
the "ambiguous nature of the claimed subject matters" of claims 6-10. Applicants* attorney 
feels that the Office's position was unwarranted and wasteful of both the attorney's and the 
Office's time as the meaning of those claims was easily ascertainable when read in light of other 
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claims and the specification. The following remarks presume that the same prior art asserted 
against claims 1 - 5 would be asserted against claims 6-10. 

Claims 1 - 5 were rejected under 35 USC 102(e) as being anticipated by the teachings of 
US Patent 6,233,589 Bl - Balcha (hereafter Balcha). For the reasons given below, the rejection 
is improper and should be withdrawn. The claims of the subject application, particularly as 
amended, arc neither anticipated by nor obvious in view of the teachings of Balcha. 

The present invention can be characterized as a byte-level approach to creating, 
distributing and using file update packages. Tn accordance with the present invention, an original 
base file is compared to a modified form of that file to identity all of the bytc-lcvcl code 
sequences which are common to the two files; i.e., code sequences which are not modified. Each 
of those sequences is identified by byte offsets representing the location of the sequence within 
the original base file. The comparison also identifies code that does not exist in the original base 
file but is being introduced into the modified form of that file. 

A delta package intended for distribution to devices to be updated from the original base 
file includes the byte offsets representing the byte-level code sequences that are not being 
changed interspersed with new code sequences. The delta package also includes a single data 
integrity code, such as a Cyclical Redundancy Check character, generated by processing the 
entire original base file. 

When such a delta package is received at a device currently having what is assumed to be 
the original base file, the data integrity code in the package is compared to the data integrity code 
associated with the corresponding file in the device. A match between the package code and the 
device code confirms that the device does contain the entire original base file in an uncorrupted 
state. A mismatch terminates the update operation. A match causes the receiving device to 
begin processing the contents of the delta package. Code identified by a pair of byte offsets in 
the delta package is copied from the original base file at the receiving device into a temporary 
store. The copied sequence is followed by one of the new code sequences. The process of 
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building a modified form of the original base file continues with repeated use of unchanged code 
sequences and new code sequences until the complete file is built, 

Balcha does not disclose a byte-level approach to building and distributing file update 
packages. Balcha uses what can be characterized as a block-level approach. Balcha divides the 
base file into multiple blocks, all of the same size, and calculates what is described as a "base bit 
pattern" for each block. Each "base bit pattern" is actually a check character such as a CRC 
character. Balcha then generates a base signature file that includes the base bit pattern for each 
of the multiple blocks. The update or delta file that is created includes multiple block-based bit 
patterns along with new code. 

At the device to be updated, the base bit patterns are compared to bit patterns generated 
for blocks in the base file resident in the device to be updated. If a match is found, the block 
found in the device is reused. The reused block can be followed by new code. 

The claims of the subject application make it clear that a single d ata integrity code (or 
CRC character) is employed in the file update process defined by the claims. For example, claim 
1 now recites that a single data integrity code is generated based on the entire contents of the base 
file. Similar language now appears in claim 7. The use of a single data integrity code based on 
the entire base file is in stark contrast to the Balcha teachings that the base file is broken up into 
uniformly-si^ed blocks and that a "data integrity code'* code is generated for each of the blocks. 

Moreover, the data integrity codes are used for different purposes. In Applicants' 
invention, the single data integrity code that is generated is used to verify that the device to be 
updated has a valid, uncorruptod copy of the entire base file before any update operations 
commence. In the Balcha system, the multiple codes arc used to identify corresponding blocks in 
the existing file already present at the system to be updated. 

Balcha neither discloses nor suggests the use of a single data integrity code. The use of a 
single code with be inconsistent with the Balcha premise that the file to be updated must be 
broken up into multiple blocks of the same size and a code generated for each block, primarily as 
a means of identifying corresponding blocks at a receiving device. 
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Since all claims in the application now clear recite the use of the single data integrity 
code, something Balcha neither disclosures nor suggests, it is submitted the claims define 
patentable subject matter over Balcha. 

It is requested that the rejections of the claims be withdrawn and the application passed to 

issue. 



Respectfully Submitted, 

Gerald R. Woods, Reg. No. 24,144 
Attorney of Record 



TBM Corporation 
T81/503 
POBox 12195 

Research Triangle Park, NC 27709 
919-(919) 543 - 7204 
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